packages/backend/src/lib/events.ts (2)

10-10: 未使用の EventEmitter を削除してください。

EventEmitter をインポートしてインスタンス化していますが、実際には使用されていません。ハンドラの登録と呼び出しはすべて Map を使って独自に実装されています。setMaxListeners(100) の設定も効果がありません。

♻️ 提案する修正

-import { EventEmitter } from "events";
 import type { PluginEvents, PluginEventPayload } from "../plugins/types.js";
 import { logger } from "./logger.js";

 export class EventBus {
-  private emitter: EventEmitter;
   private handlers: Map<string, HandlerEntry<unknown>[]>;
   private beforeHandlers: Map<string, HandlerEntry<unknown>[]>;

   constructor() {
-    this.emitter = new EventEmitter();
-    this.emitter.setMaxListeners(100);
     this.handlers = new Map();
     this.beforeHandlers = new Map();
   }

Also applies to: 79-87

---

212-252: emitBefore の戻り値の仕様を確認してください。

ハンドラが存在するが変更がなかった場合でも { modifiedPayload: currentPayload } を返しています。これは意図的な設計と思われますが、呼び出し側が「変更なし」と「同じ値に変更」を区別できません。

現在の設計で問題ない場合は、TSDocコメントに「ハンドラが存在する場合は常に modifiedPayload を返す」旨を明記すると、利用者にとって分かりやすくなります。

packages/backend/src/tests/unit/EventBus.test.ts (1)

25-52: テストペイロードのヘルパー関数を検討してください。

同じ構造のペイロードオブジェクトが複数のテストで繰り返されています。テストヘルパー関数やファクトリを作成すると、コードの重複を減らし、変更時のメンテナンスが容易になります。

♻️ 例：ヘルパー関数の作成

// テストファイルの先頭に追加
function createTestNotePayload(overrides?: Partial<NoteAfterCreatePayload>): NoteAfterCreatePayload {
  return {
    note: {
      id: "note1",
      userId: "user1",
      text: "Hello",
      cw: null,
      visibility: "public",
      localOnly: false,
      replyId: null,
      renoteId: null,
      fileIds: [],
      mentions: [],
      uri: null,
      createdAt: new Date(),
    },
    author: {
      id: "user1",
      username: "alice",
      displayName: null,
      avatarUrl: null,
      host: null,
      isAdmin: false,
      isSuspended: false,
      isSystemUser: false,
      uri: null,
      createdAt: new Date(),
    },
    ...overrides,
  };
}

packages/backend/src/services/FollowService.ts (1)

214-227: followIdの複合ID形式について確認してください。

削除済みのフォロー関係では元のIDが利用できないため、${followerId}:${followeeId}という複合IDを使用していますが、プラグイン開発者がこの形式を期待するか確認が必要です。

プラグイン型定義（PluginEvents）でこのIDフォーマットがドキュメント化されているか確認することをお勧めします。

#!/bin/bash
# follow:afterDelete イベントのペイロード型定義を確認
rg -n -A 10 "follow:afterDelete" packages/backend/src/plugins/types.ts

packages/backend/src/services/NoteService.ts (1)

113-149: toPluginUserとtoPluginNoteヘルパーの重複について検討してください。

これらの変換ヘルパーはAuthService（そしておそらくFollowService）にも存在する可能性があります。共通のユーティリティに抽出することで、変換ロジックの一貫性を保ち、メンテナンス性を向上させることができます。

♻️ 提案: 共通ユーティリティへの抽出

packages/backend/src/plugins/utils.tsのような共有ファイルを作成することを検討してください:

import type { User } from "shared";
import type { Note } from "shared";
import type { PluginUser, PluginNote } from "./types.js";

export function toPluginUser(user: User): PluginUser {
  return {
    id: user.id,
    username: user.username,
    displayName: user.displayName,
    avatarUrl: user.avatarUrl,
    host: user.host,
    isAdmin: user.isAdmin,
    isSuspended: user.isSuspended,
    isSystemUser: user.isSystemUser,
    uri: user.uri,
    createdAt: user.createdAt,
  };
}

export function toPluginNote(note: Note): PluginNote {
  return {
    id: note.id,
    userId: note.userId,
    text: note.text,
    cw: note.cw,
    visibility: note.visibility,
    localOnly: note.localOnly,
    replyId: note.replyId,
    renoteId: note.renoteId,
    fileIds: note.fileIds,
    mentions: note.mentions,
    uri: note.uri,
    createdAt: note.createdAt,
  };
}

packages/backend/src/routes/auth.ts (1)

245-259: x-forwarded-for を先頭 IP に正規化したい
Line 257 で x-forwarded-for をそのまま渡すと複数 IP がカンマ区切りで入る可能性があり、プラグイン/監査側の扱いが不安定になります。先頭 IP のみ抽出して渡すのが安全です。

♻️ 提案修正

-        ipAddress: c.req.header("x-forwarded-for") || c.req.header("x-real-ip") || undefined,
+        ipAddress: (() => {
+          const forwarded = c.req.header("x-forwarded-for");
+          if (forwarded) return forwarded.split(",")[0].trim();
+          return c.req.header("x-real-ip") || undefined;
+        })(),

packages/backend/src/tests/unit/EventBus.test.ts (1)

108-126: ペイロード変更テストの型安全性を確認してください。

Line 114で payload.text?.toUpperCase() を使用していますが、NoteBeforeCreatePayloadのtextはstring | null型です。オプショナルチェーンは適切ですが、戻り値がnullの場合の処理を確認してください。

🔧 より明示的な null ハンドリングの提案

       eventBus.onBefore(
         "note:beforeCreate",
         async (payload) => ({
           modifiedPayload: {
             ...payload,
-            text: payload.text?.toUpperCase() || null,
+            text: payload.text !== null ? payload.text.toUpperCase() : null,
           },
         }),
         "modifier-plugin"
       );

packages/backend/src/services/FollowService.ts (1)

197-210: follow:afterDeleteの複合IDについてドキュメント化を検討してください。

Line 203で ${followerId}:${followeeId} という複合IDを使用していますが、プラグイン開発者がこの形式を期待していない可能性があります。PluginFollowのidフィールドとは異なる形式になるため、プラグインAPIドキュメントでこの動作を明記することを推奨します。

📝 コメントの追加提案

     // Emit follow:afterDelete event (async, non-blocking)
     // Only emit if the relationship existed and we have valid user info
     if (this.eventBus && exists && follower && followee) {
       this.eventBus
         .emit("follow:afterDelete", {
-          followId: `${followerId}:${followeeId}`, // Composite ID since we don't have the original
+          // Note: Using composite ID format "followerId:followeeId" since the original
+          // follow record ID is not available after deletion. Plugin developers should
+          // be aware that this differs from the `follow.id` in afterCreate events.
+          followId: `${followerId}:${followeeId}`,
           follower: toPluginUser(follower),
           followee: toPluginUser(followee),
         })

packages/backend/src/tests/helpers/pluginTestHelpers.ts (1)

53-107: 他のイベントペイロード用のファクトリ追加を検討してください。

現在、Note関連のbeforeCreateとafterCreateのペイロードヘルパーのみ実装されています。将来的に以下のヘルパーも追加すると、テストの一貫性が向上します：

• createNoteBeforeDeletePayload
• createNoteAfterDeletePayload
• createFollowAfterCreatePayload
• createFollowAfterDeletePayload

packages/backend/src/lib/events.ts (1)

211-251: emitBefore()のエラーハンドリングについて確認してください。

現在の実装では、beforeハンドラーでエラーが発生してもキャンセルせずに処理を続行します。これは意図的な設計かもしれませんが、セキュリティ関連のプラグイン（スパムフィルターなど）がエラーで失敗した場合、操作が続行されるリスクがあります。

この動作が意図的であれば、JSDocコメントにその旨を明記することを推奨します。

📝 エラー動作のドキュメント化

   /**
    * Emit a "before" event and collect cancellation/modification results
    *
    * Handlers are executed in priority order. If any handler cancels,
    * the operation should be aborted.
+   *
+   * `@remarks`
+   * If a handler throws an error, it is logged but processing continues.
+   * This means security-critical plugins should handle their own errors
+   * and return `{ cancelled: true }` explicitly rather than throwing.
    *
    * `@param` event - Before event name

packages/backend/src/plugins/types.ts (1)

35-38: 可視性フィールドをユニオン型にして型安全性を強化する

PluginNote.visibility と NoteBeforeCreatePayload.visibility が string だと無効値が混入しやすいです。既存の Visibility 型（shared/src/types/common.js）が "public" | "home" | "followers" | "specified" として定義されており、NoteService や ScheduledNoteService で既に使用されています。このプラグイン型でも同じ Visibility 型を import して使用することで、型安全性と一貫性が向上します。